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L REAL PARTY IN INTEREST 

The real party in interest is the assignee of the full interest in the invention, Sonics, Inc., 
2440 West El Camino Real, Suite 620, Mountain View, California 94040. 



IL RELATED APPEALS AND INTERFERENCES 

To the best of Appellant's knowledge, there are no appeals or interferences related to the 
present appeal that will directly affect, be directly affected by, or have a bearing on the Board's 
decision in the instant appeal. 

IIL STATUS OF CLAIMS 

Claims 12-22 are pending in the application and were rejected in the Office Action 
mailed July 17, 2006, after prosecution was reopened by the Examiner. In particular, claims 12- 
22 stand rejected under 35 U.S.C. § 103(a) as being unpatentable over U.S. Patent No. 6,216,259 
to Guccione et al (hereinafter "Guccione"). Additionally, claims 12-22 stand rejected under 35 
U.S.C. § 103(a) as being unpatentable over U.S. Patent No. 6,510,546 to Blodget 
(hereinafter "Blodget"). 

Claims 12-22 are the subject of this appeal. A copy of claims 12-22 as they stand on 
' appeal is set forth in the Claims Appendix. 

IV. STATUS OF AMENDMENTS 

No amendments have been submitted subsequent to the Office Action mailed July 17, 

2006. 



V. SUMMARY OF CLAIMED SUBJECT MATTER 

This section of this Appeal Brief is set forth to comply with the requirements of 37 
C.F.R. § 41.37(c)(l)(v) and is not intended to limit the scope of the claims in any way. 
Exemplary implementations of the limitations of independent claims 12, 16, and 19 are described 
below. 

Independent claim 12 relates to a new computer core having an interface to communicate 
with other cores. Figure 2B. The interface contains a plurality of interface signal carriers that 
are configurable, at compilation, such that at least one of the interface signal carriers is 
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selectively physically present in the interface or not physically present. Not physically present 
means that a route connection is not generated for an interface signal carrier selected to be not 
physically present. Figure 2B and Specification, p. 7, lines 1 1-25. The configuration of whether 
a signal is present or not is also referred to as "signal enabling." Specification, p. 8, lines 23-26. 
Figure 4 shows one example of a configurable core interface in which signal enabling is used. A 
"Y" in the Signal Enabling column indicates that the named signal is configurable, and an "N" 
indicates that the named signal is not configurable. Figure 4. 

Independent claim 16 relates to a core on a system on a chip having an interface. Figure 
2B. The interface contains a plurality of interface signal carriers that are configurable, at 
compilation, such that a first interface signal carrier of the plurality of interface signal carriers is 
configurable to support different levels of functionality for the interface. Figure 2B and 
Specification, p. 7, lines 1 1- 25. 

Independent claim 19 relates to a method for generating at compilation a core interface 
for a system on a chip to enable re-use of the core with a different interface configuration. 
Figure 6. Configurable source code representative of the core interface for the system on a chip 
and identifying parameters of the core interface is provided. Configuration parameters of the 
core interface are defined. The core interface for the system on a chip from the configurable 
source code representative of the core interface and the identified parameters of the core 
interface configurable in accordance with the defined configuration parameters of the core 
interface are generated. Specification, p. 9, line 21, to p. 10, line 17. 

VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

A. Whether the rejections based on Guccione are proper given Appellant's prior traversal of 
Guccione. 

B. Whether claims 12-22 are patentable under 35 U.S.C. § 103(a) over Guccione. 

C. Whether the substance of Appellant's declaration under 37 C.F.R. § 1.131 is adequate to 
overcome the rejection of claims 12-22 under 35 U.S.C. § 103(a) based on Blodget. 
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VIL ARGUMENT 

For the purposes of this appeal, the claims stand or fall together. 

A. Claims 12-22 are patentable over Guccione because the Examiner already determined 
that the claims overcome Guccione. 

Claims 12-22 stand rejected under 35 U.S.C. § 103(a) as being unpatentable over 
Guccione. However, the current Office Action appears to disregard the Examiner's previous 
determination that claims 12-22 overcome Guccione. 

During prosecution of the present application, Appellant submitted nev^ claims 12-22 in a 
response mailed December 30, 2003. In connection with this amendment. Appellant and the 
Examiner held a telephone conference on December 30, 2003, during which claims 12-22 were 
discussed. Among other things. Appellant explained to the Examiner that differences between a 
field programmable gate array (FPGA) described in Guccione and a system-on-a-chip (SoC), as 
recited in at least some of the claims of the present application. Following this telephone 
conference, the Examiner mailed an Interview Summary on January 6, 2004, to summarize the 
discussions of claims 12-22. In the Interview Summary, the Examiner expressly stated the 
following: 

"Examiner determined that the proposed claim amendments would 
overcome the prior art of record [Guccione] and require a new search." 
Interview Summary, December 30, 2004 (emphasis added). 

It should be noted that the Examiner's determination was stated generally, and was not 
limited to a particular type of rejection. Rather, die Examiner clearly stated that claims 12-22 
overcome Guccione, which was the prior art reference on which the rejections were based at that 
time. The basis for the Examiner's statement was the added limitation that device is 
configurable such that "at least one of the interface signal carriers is selectively physically 
present in the interface or not physically present, wherein not physically present means that a 
route connection is not generated for an interface signal carrier selected to be not physically 
present." The Examiner acknowledge that each instance of a particular type of FPGA will have 
all of the transistors and physical connections as another instance of that particular type of 
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programmable logic device (PLD). Guccione merely discusses PLDs. The same limitation is 
still present in the claims at issue now a couple years later. Therefore, the Examiner's statement 
from the Interview Summary should apply to Guccione regardless of whether Guccione is used 
as the basis for a rejection under 35 U.S.C, § 102 or § 103. The subject matter disclosed in 
Guccione has not changed. Accordingly, Appellant respectfully requests that the current 
rejection of claims 12-22 under 35 U.S.C. 103(a) based on Guccione be withdrawn. 

Moreover, Appellant submits that reopening prosecution of the present application based 
on the "new" rejection using Guccione was improper because the rejection using Guccione was 
not a new rejection. The M.P.E.P. allows an examiner to "reopen prosecution to enter a new 
ground of rejection" after an appellant files an appeal brief or reply brief. M.P.E.P. § 1207.04. 
However, the M.P.E.P. does not authorize an examiner to reopen prosecution based on an old 
rejection that has previously been overcome. In the present case, the Guccione reference was 
previously overcome, as explained above. Thus, the Guccione reference was not a new 
reference. Given that Guccione reference was not a new reference, and the M.P.E.P. merely 
allows an examiner to reopen prosecution based on a new reference, Appellant respectfully 
submits that the Examiner's actions in reopening prosecution of the present case was improper. 

Furthermore, Appellant notes that the current appeals rules were implemented with the 
purpose of reducing the pendancy of patent applications. See Federal Register , Vol. 69, No. 155, 
p. 49963, describing 37 C.F.R. § 41.39(a)(2). While these comments are stated specifically in 
connection with a discussion of the procedure for an examiner's answer. Applicant submits that 
the same purpose of reducing pendancy applies to other aspects of the appeal process, including 
reopening prosecution. Specifically, these comments indicate that the appeal process should 
proceed in an orderly manner to decrease pendency, rather than to increase pendancy — which is 
happening in this present application. Here, the claims were last amended in Appellant's 
response mailed December 30, 2003. No substantive amendments have been submitted since 
that time. Since that amendment, the Examiner stated that claims 12-22 were patentable over 
Guccione, issued a new rejection based on Blodget which Appellant has previously appealed, 
and reopened prosecution using similar rejections based on both Guccione and Blodget, despite 
the Examiner's concession that claims 12-22 overcome the rejections based on Guccione. Given 
that the Examiner continues to issue rejections based on old references, which Appellant has 
successfully argued over or for which Appellant has submitted a thorough declaration, and given 
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that the Examiner has reopened prosecution based on these same old references, it appears that 
the Examiner is simply attempting to avoid the appeal process. In other words, Appellant 
respectfully submits that the Examiner is denying timely prosecution of this application by 
preventing appellate review of the present application, in disregard for the stated purpose of the 
appeal process to reduce prosecution pendancy. The Examiner has previously tried to prevent 
the appeals process by stating that the 1.31. Declaration was insufficient out of the blue. 

The Examiner's action of reopening prosecution of the present case based on only 
references that were either overcome (Guccione) or pending appeal (Blodget) is a blatant 
disregard for Appellant's attempt to advance prosecution in a timely manner. In regard to the 
"new" rejection based on Guccione, Applicant respectfully submits that the same arguments 
apply to Guccione today as applied three years ago. In other words, the reasons why claims 12- 
22 are patentable over Guccione are the same today as they were three years ago when the 
Examiner stated that claims 12-22 overcame Guccione. However, right now Appellant addresses 
the procedural and logical correctness of reopening this case when the current appeals rules are 
intended to decrease — not increase — the pendency period for applications. As discussed above 
and below, virtually the same arguments found to be persuasive in this Appeal Brief can be 
found in the Appellant's response dated December 27, 2003. Therefore, Appellant respectfully 
requests that the Board acknowledge that reopening prosecution of the present application based 
on a previous reference, Guccione, which was overcome approximately three years ago, was 
improper. 

B. Claims 12-22 are patentable over Guccione because Guccione does not teach or suggest 
all of the limitations of the claims. 

Claims 12-22 stand rejected under 35 U.S.C. § 103(a) as being unpatentable over 
Guccione. However, Applicant respectfully submits that claims 12-22 are patentable over 
Guccione because Guccione does not teach or suggest all of the limitations of the claims. 

Guccione discloses a configurable programmable logic device (PLD), which receives 
program instructions on how to logically program its existing physical connections. Guccione, 
col. 3, line 66, to col. 4, line 10. The programming instructions/bits are loaded into the 
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programmable logic device to configure the device. Claim 1 of Guccione provides an overview 
of the disclosure: 

1 . A method for configuration of a programmable logic device that is coupled to 
a processor using a library that comprises logic core generators and one or more 
router core generators, each of the logic and router core generators including code 
that is executable and embodies design information, comprising the steps of: 
executing a program on the processor, the program including instructions that 
reference selected ones of the logic core generators for functions to be provided 
by the programmable logic device; 

generating by one or more of the logic core generators in response to the 
program, logic core definitions that define at least two logic cores; 

generating by the router generators in response to the program, at least one 
router core definition that defines a coupling of the logic cores in the 
programmable logic device ; 

generating progranaming bits from the logic core definitions and router 
core definition in response to the program; and 

loading the programmable logic device with the programming bits in 
response to the program. 
Col. 15, lines 1-10 (emphasis added). 

Guccione warns that a user must take care when configuring a connection between two 
configurable blocks of logic (CLB) on the programmable logic device because the existing 
connection between CLBs may already be in use by another system resource. Specifically, 
Guccione states: 

This router core object has a width of zero because it consumes no CLB logic. 
This core uses the direct connect signal lines between CLBs. Note that since the 
present method replaces a more elaborate automatic routing algorithm, it is left to 
the user to ensure that these routing resources are not in use. 
Col. 11, lines 7-12 (emphasis added). 

In other words, Guccione merely teaches using a programmable logic device with 
existing physical connections between the various cores. These physical connections are always 
there, and the logic simply turns the connections on or off. Guccione does not teach using a 
programmable logic device which has physical connections that can be selectively present or not 
present. For example, there is no teaching in Guccione of how to potentially physically remove 
an existing direct connect signal line between CLBs. 

In contrast, independent claim 12 states: 
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12. A computer core having an interface to communicate with other cores, 
wherein the interface contains a plurality of interface signal carriers that are 
configurable, at compilation, such that at least of one of the interface signal 
carriers is selectively physically present in the interface or not physically present , 
wherein not physically present means that a route connection is not generated for 
an interface signal carrier selected to be not physically present. 
(Emphasis added). 

Given that Guccione does not disclose interface signal carriers that are configurable such 
that the interface signal carriers may be selectively physically present in the interface or not 
physically present, Appellant respectfully submits that claim 12 is patentable over Guccione. 
Given that claims 13-15 depend from and include the limitations of claim 12, Appellant submits 
that claims 13-15 are also patentable over Guccione. Accordingly, Appellant requests that the 
rejection of claims 12-15 under 35 U.S.C. § 103(a) be withdrawn. 

Similarly, Appellant respectfully submits that claim 16 is also patentable over Guccione. 
Guccione discloses that a core on the disclosed programmable logic device is a block logic to 
provide an elementary level function such as adding, multiplying, on/off flip flops, etc. 
Specifically, Guccione discloses: 

The core library 206 is a collection of macrocell or "core" generators that are 
implemented as Java classes. The cores are generally parameterizable and 
relocatable within a device. Examples of cores include counters, adders, 
multipliers, constant adders, constant multipliers, flip-flops and other standard 
logic and computation functions . 
Col. 4, lines 39-45 (emphasis added). 

Guccione also discloses: 

Selected functions provided by the core library 206 (FIG. 2) are invoked at step 
304 to generate logic core definitions. The functions selected are those required to 
generate one or more logic cores for implementation on the programmable logic 
device . 

Col. 5, lines 39-43 (emphasis added). 

In other words, Guccione merely discloses cores only on a programmable memory 
device. Guccione does not disclose a core with an interface on a system-on-a-chip (SoC). 
New independent claim 16 states: 
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16. A core on a system on a chip having an interface , wherein the interface 
contains a pluraUty of interface signal carriers that are configurable, at 
compilation, such that at least of a first interface signal carriers is configurable to 
support different levels of functionality for the interface . 
(Emphasis added). 

Given that Guccione does not disclose a core on a system-on-a-chip that has an interface, 
which is configurable to support different levels of functionality for the interface, Appellant 
respectfully submits that claim 16 is patentable over Guccione. Given that claims 17 and 18 
depend from and include the limitations of claim 16, Appellant submits that claims 17 and 18 are 
also patentable over Guccione. Accordingly, Appellant requests that the rejection of claims 16- 
18 under 35 U.S.C. § 103(a) be withdrawn. 

Similarly, applicant respectfully submits new claim 19 is patentable over Guccione. 
Claim 19 discloses: 

19. A method for generating at compilation a core interface for a system on a 

chip to enable re-use of the core with a different interface configuration , the 

method comprising: 

providing configurable source code representative of the core interface for 

the system on a chip and identifying parameters of the core interface; 
defining configuration parameters of the core interface; and 
generating the core interface for the system on a chip from the 

configurable source code representative of the core interface and the identified 

parameters of the core interface configurable in accordance with the defined 

configuration parameters of the core interface. 
(Emphasis added). 

As explained above, Guccione does not disclose a core interface for a core on a system- 
on-a-chip to enable re-use of the core with a different interface configuration. Moreover, 
Guccione does not disclose generating the core interface for the system-on-a-chip from the 
configurable source code representative of the core interface and the identified parameters of the 
core interface configurable. 

Given that Guccione does not disclose all of the limitation of the claim. Appellant 
respectfully submits that claim 19 is patentable over Guccione. Given that claims 20-22 depend 
from and include the limitations of claim 19, Appellant submits that claims 20-22 are also 
patentable over Guccione. Accordingly, Appellant requests that the rejection of claims 19-22 
under 35 U.S.C. § 103(a) be withdrawn. 
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C. Claims 12-22 are patentable over Blodget because Appellant's Declaration under 37 

C.F.R. § L131 establishes invention of the subject matter of the claims 12-22 prior to the 
effective date of Blodget. 

Claims 12-22 stand rejected under 35 U.S.C. § 103(a) as being unpatentable over 
Blodget. However, the current Office Action dismisses Appellant's previous appeal regarding 
the sufficiency of Appellant's Declaration under 37 U.S.C. § 1.131. In particular, the current 
Office Action restates the rejection based on Blodget which was the subject matter of the most 
appeal. Rather than allow the Board to address the merit of Appellant's Declaration, the 
Examiner reopened prosecution based on a "new" rejection (the rejection based on Guccione 
was, in fact, not new, as explained above), and restates the rejection based on Blodget which was 
the subject matter of the appeal. Thus, it appears that the Examiner is attempting to maintain the 
rejection based on Blodget, even though Appellant initiated the appeal to determine the merit of 
Appellant's declaration. Despite the Examiner's assertion that prosecution was reopened "in the 
interest of compact prosecution," this action by the Examiner merely delays Appellant's 
opportunity to have the merit of Appellant's Declaration properly reviewed. 

Therefore, Appellant respectfully submits that Appellant's Declaration was proper and 
adequate to remove Blodget as a prior art reference, according to Appellant's arguments and 
remarks presented in the Appeal Brief filed December 27, 2004, and Appellant's Supplemental 
Appeal Brief filed October 6, 2005. 

By way of review, Blodget qualifies as prior art only under 35 U.S.C. § 102(e) because 
its filing date of July 13, 2000 is earlier than Appellant's filing date of August 8, 2000, and its 
issue date of January 21, 2003 is later than Appellant's filing date. Appellant submitted a 
Declaration under 37 C.F.R. § 1.131 on August 17, 2004, with accompanying Exhibits, to 
establish that the invention as claimed in claims 12-22 was reduced to practice prior to the July 
13, 2000 filing date of Blodget. Therefore, Blodget is not available as prior art under 35 U.S.C. 
§ 102(e). In the Advisory Action mailed October 18, 2004, the Examiner indicated that the 
Declaration filed did not place the application in condition for allowance because "a review of 
the declaration under 37 CFR 1.131 and evidence submitted therein raises questions regarding 
the 35 use 102(b) bar to patentability based upon public use or sale one year prior to the filing 
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of the instant application." Advisory Action, October 18, 2004, p. 2. The Examiner did not 
indicate, in the Advisory Action or in subsequent telephone conversations, exactly what portions 
of the Declaration raised 35 U.S.C. § 102(b) questions. Appellant notes that among the Exhibits 
submitted with the Declaration filed on August 17, 2004, all but two dates were redacted from 
the Exhibits. The two revealed dates, September 16, 1999, and September 7, 1999, are the 
publication dates of two press releases presented as Exhibits E and F, respectively. Appellant 
notes that neither of these dates are more than one year prior to the filing date of the present 
application, which is August 8, 2000. 

Moreover, the Declaration in point 2 first stated that the inventors reviewed the claims as 
they currently stand in Appendix A. All five inventors then declared in points 5 and 6 based on 
their review of the current claims that those concepts were contained in the Sonics SOC 
Integration Suite product as evidenced in their beliefs by the Purchase order and Invoice to 
VxTel. All five inventors next declared in point 7 based on their review of the current claims 
that those concepts were indeed contained in the selected sections of the product manual 
submitted as evidence. All five inventors also declared in points 8 and 9 based on their review of 
the current claims that those concepts were reduced to practice prior to July 13, 2000, as 
evidenced in their beliefs by the supporting Press Articles. Note that two of the individuals 
making this Declaration are no longer employed by assignee. Appellant, respectfully submit the 
unified declaration of five different individuals referencing the accompanying documentary 
evidence should be sufficient to establish a reduced to practice of the currently claimed invention 
prior to July 13, 2000. All five inventors also declared that the filing of the patent application 
was on or before a one year bar date. 

Accordingly, Appellant respectfully requests that the Board decree some finality to the 
prosecution of this patent application. This patent application has withstood several office 
actions, an abandonment and subsequent revival due to a phone call with this same examiner 
trying to resolve a mistake on a PTO form send by this examiner, a telephone interview in which 
the Examiner conceded that the claims overcame the prior art, an appeal regarding the 
sufficiency of the inventor's Declaration, and ultimately reopening prosecution based on the 
prior art that was previously overcome. The substantive merits of the claims have been 
thoroughly discussed and the Examiner even in at least the telephonic Interview Summary that 
the claims were different than the prior art. However, after all of this, the Examiner has issued 
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another office action rejection based on the already discussed and distinguished prior art. 
Additionally, when Appellant attempted to further prosecution and overcome another prior art by 
submitting a 1.131 declaration including its supporting documentation, the Examiner has taken 
steps to obstruct advancement of this application, rather than discuss the substantive merits of the 
claims. If the Board feels the 1.131 declaration including its supporting documentation are 
sufficient to establish an invention date prior to the reference's priority date, then the Appellant 
respectfully requests that the Board withdraw the rejection under 35 U.S.C. § 103(a) based on 
Blodget and decree a Notice of Allowance for this patent application. Further, if the Board 
agrees that Guccione disclosed a PLD with physical connections always present just logically 
turn on or off, then the Board needs to decree a Notice of Allowance for this patent application 
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VIII, CONCLUSION 



Based on the foregoing, claims 12-22 are patentable over the cited references of 
Guccione and Blodget under 35 U.S.C. § 103(a). Thus, the rejections of claims 12-22 should be 
withdrawn. Accordingly, Appellant respectfully requests that the Board reverse the rejections of 
claims 12-22. Appellant is entitled to a full and through examination each time the PTO reviews 
the merits of this application. Accordingly, since there are no remaining grounds of rejection to 
be overcome, please direct the Examiner to enter a Notice of Allowance for claims 12-22. 
Alternatively, Appellant requests the Board to exercise its authority to enter a Notice of 
Allowance for claims 12-22. 

Additionally, Appellant notes that this is Appellant* s second attempt to move the present 
application out of the Examiner's jurisdiction because the facts on the record indicate that the 
Examiner is simply stalling the prosecution of this patent application. Something should be done 
to fix this process. 

If there are any additional charges, please charge Deposit Account No. 02-2666. 



Respectfully submitted, 



Blakely, Sokoloff, Taylor & Zafman LLP 




Jeffre5rB! 
Reg. No. 51,812 



12400 Wilshire Boulevard 
Seventh Floor 



Los Angeles, CA 90025 
(408) 720-8300 
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IX. CLAIMS APPENDIX 

Claims 1-11 (Canceled) 

12. (Previously presented) A new computer core having an interface to communicate with 
other cores, wherein the interface contains a plurality of interface signal carriers that are 
configurable, at compilation, such that at least one of the interface signal carriers is selectively 
physically present in the interface or not physically present, wherein not physically present 
means that a route connection is not generated for an interface signal carrier selected to be not 
physically present. 

13. (Previously presented) The computer core as set forth in claim 12, wherein the computer 
core is a core on a system on a chip and the other cores also belong to that system on a chip. 

14. (Previously presented) The computer core as set forth in claim 12, wherein a first 
interface signal carrier is further configured to support different levels of functionality for the 
interface. 

15. (Previously presented) The computer core as set forth in claim 14, wherein a signal 
carrier width of the first interface signal carrier is also configurable to support different signal 
widths. 

16. (Previously presented) A core on a system on a chip having an interface, wherein the 
interface contains a plurality of interface signal carriers that are configurable, at compilation, 
such that a first interface signal carrier of the plurality of interface signal carriers is configurable 
to support different levels of functionality for the interface. 

17. (Previously presented) The core as set forth in claim 16, wherein a signal carrier width of 
the first interface signal carrier is also configurable to support different signal widths. 

18. (Previously presented) The core as set forth in claim 16, wherein the first interface signal 
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carrier is configurable, at compilation, such that the first interface signal carrier is selectively 
physically present in the interface or not physically present. 

19. (Previously presented) A method for generating at compilation a core interface for a 
system on a chip to enable re-use of the core with a different interface configuration, the method 
comprising: 

providing configurable source code representative of the core interface for the system on 
a chip and identifying parameters of the core interface; 

defining configuration parameters of the core interface; and 

generating the core interface for the system on a chip from the configurable source code 
representative of the core interface and the identified parameters of the core interface 
configurable in accordance with the defined configuration parameters of the core interface. 

20. (Previously presented) The method as set forth in claim 19, wherein at least one of the 
configuration parameters of the core interface is defining whether a first interface signal carrier 
will be physically present in the core interface or not physically present. 

21. (Previously presented) The method as set forth in claim 19, wherein at least one of the 
configuration parameters of the core interface is defining different levels of functionality that the 
core interface supports through a plurality of signal interface carriers. 

22. (Previously presented) The method as set forth in claim 19, wherein at least one of the 
configuration parameters of the core interface is defining a signal width of a first interface signal 
carrier. 
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X. EVIDENCE APPENDIX 

This Evidence Appendix includes a copy of the 1.131 Declaration, as well as the 
following documentation that was submitted during prosecution pursuant to 37 C.F.R. § 1,131: 
Invoice (1 page) 
Purchase Order (1 page) 
User Reference Manual, including: 

Cover Pages (2 pages) 

Table of Contents (3 pages) 

Chapter 3 - selected portions (3 pages) 

Chapter 5 - selected portions (16 pages) 
Reed Business Information Article (1 page) 
EE Times Article (3 pages) 



XL RELATED PROCEEDINGS APPENDIX 

To the best of Applicants' knowledge, there are no appeals or interferences related to the 
present appeal that will directly affect, be directly affected by, or have a bearing on the Board's 
decision in the instant appeal 
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IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 



Application of: 



Examiner: Thompson, Annette M. 



Drew Eric Wingard et al. 



Art Group: 2825 



Application No.: 09/634,045 



Confirmation No.: 5608 



Filed: Augusts, 2000 

For: LOGIC SYSTEM WITH 

CONFIGURABLE INTERFACE 



Commissioner for Patents 

P.O. Box 1450 

Alexandria, VA 22313-1450 



We, Drew Eric Wingard, Michael J. Meyer, Geert Rosseel, Lisa A. Robinson, and Jay 
8. Tomlinson, declare the following: 

1 . We are the inventors of the above identified patent application. We are also 
employees or fomner employees of the assignee, Sonics, Inc. (hereinafter "Sonics"), of the 
application. 

2. We have reviewed the application, including the claims of the application, and 
we have also reviewed a copy of the cun-ent claims which are pending (a copy of which is 
attached as Exhibit A). 

3. The declaration made herein is to establish reduction to practice prior to July 
13, 2000, which is the effective filing date of U.S. Patent 6,510,546 to Blodget. 
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DECLARATION UNDER 37 C.F.R. (5 1.131 



4. We reduced to practice the claimed invention (in the claims of Exhibit A) prior 
to July 13, 2000. 

5. Exhibit B attached herewith is an Invoice from Sonics to VxTel, Inc. 
(hereinafter "VxTel"), describing the sale of the Sonics SOC Integration Suite product prior to 
July 13, 2000. The SOC Integration Suite product included embodiments of the claimed 
invention. Exhibit B demonstrates that the claimed invention was reduced to practice prior 
to July 13, 2000. Note that the invoice date and purchase amounts have been redacted. 

6. Exhibit C attached herewith is a Purchase Order from VxTel to Sonics, 
describing the purchase of the Sonics Integration Suite product prior to July 13, 2000. The 
SOC Integration Suite product included embodiments of the claimed invention. Exhibit C 
demonstrates that the claimed invention was reduced to practice prior to July 13, 2000. Note 
that the purchase order date and purchase amounts have been redacted. 

7. Exhibit D attached herewith is product manual for the Sonics Integration Suite 
product, entitled SOCIntegrator and SOCBuilder User Reference. The product manual 
accompanied the sale of the Sonics Integration product described above, prior to July 13, 
2000. Embodiments of the invention are supported throughout the entire product manual, 
but are more specifically described starting at page 32, and in general in Chapter 5 at page 
43 of the manual. Exhibit D demonstrates that the claimed invention was reduced to 
practice prior to July 13, 2000. 

8. Exhibit E attached herewith is a press release from EDN dated September 
16, 1999, entitled Design Suite Accelerates SOC Development. The press release 
describes some aspects of the functionality of the Sonics SOC Integration Suite. Exhibit E 
demonstrates that the claimed invention was reduced to practice prior to July 13, 2000. 

9. Exhibit F attached herewith is a press release from EE Times dated 
September 7, 1999, entitled Sonics Spins SoC Plug-and-play Tool. The press release 
describes some aspects of the functionality of the Sonics SOC Integration Suite. Exhibit F 
demonstrates that the claimed invention was reduced to practice prior to July 13, 2000. 



Serial No.: 09/634,045 
Filed: 08/08/2000 



2/3 



Attorney Docket No.: 2998.P011 



) 



10. Based on the above description and as is evident from the attached exhibits, 
reduction to practice of the subject matter, for its intended purpose, was accomplished at 
least prior to July 13, 2000. 



11. We declare, to the best of our knowledge, that all statements made in this 
document are true, and that all statements made on the information and belief are believed 
to be true; and further that these statements were made with the knowledge that willful false 
statements and the like so made are punishable by fine or imprisonment, or both, under 
§ 1001 of Title 18 of the United States Code, and that such willful false statements may 
jeopardize the validity of the above-identified patent application or any patent issued 
thereon. 



Dated: ^/ /O / Qo^ 
Dated: 

Dated: ^Ijlj^O^^ 



Name: Drew Eric Wingard 




Name: Michael SJMeyer 
(Se^ Rqeseel 




Dated: 



' ' Name: ue^ft Roseeel 



Dated: '^/jlj2ae>Y 



Name: Lisa A. Robinson 
Nam^ Jay S. Tomlinson 
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Sonics, Inc, 

2440 W. EI Camino Real, Suite 620 
Mountain View, California 94040 

Telephone: (650)938-2500 
Fax: (650)938-2577 
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DATE 


INVOICE # 




30 



BILL TO 



VxTel Inc. 

Attn: Sanjeev Renjen, PhD. 
47697 Westinghouse Drive 
Suite ]00 

Fremont, CA 94539 



SHIP TO 



VxTel Inc. 

Attn: Sanjeev Renjen, PhD. 
47697 Westinghouse Drive 
Suite 100 

Fremont. CA 94539 



P.O. NO. 



TERMS 



51805 



Net 30 



DESCRIPTION 



AMOUNT 



Sonics Integration Architecture 2.1 
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00 
00 
00 



Thank you for your business. 



Total 



VxTel, Inc. 
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Suite 100 
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Tel: (510)979-2100 Fax:(510)979-2107 



Purchase Order 



DATE 


P.O. NO. 
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Vendor 
Sonics. Inc. 
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MounuiQ Vieo/, CA 94040 



SHIP TO 

George Moussa 
9^4-2 Alpine Terrace 
Sunnyvale, CA 940^6 





QUOTE NO. 


TERMS 


SHIP DATE 


SHIP VIA 


CONTACT 




VXI22399-TY 


Net 30 Days 




Electronic 


Saiyecv Rensen 



DESCRIPTION 



QTY 



RATE 



AMOUI>rr 



SonicsIA - Imegiated Architecture Core License - Release 2.0 

Sonics SOC Intcgraticn Suite - Annual Subscription price includes 
one license each of Sosnics SOCIuegraior, SOC Builder and Core 
CrcaiOT 

Sonics SOC Integration Suite - Annual Maimenancc 
Sent Via Electronic Transmission 



00 
.00 

.00 



.00 
.00 

..00 



Total 



) 1 
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Package Core 

The final step of CoreCreator is the packaging of the core. In this step, the 
various representations of the core (such as RTL or gate-level netlist), 
synthesis scripts and configuration files (If applicable), test benches, and 
documentation, are collected together into a single package for convenient 
delivery to the system integrator. 

The items to be included in the core package are specified using a package 
file. This file needs to be set up using a text editor, no matter whether the GUI 
or command line Interface is used. In the GUI. there is a separate flow button 
for packaging the core. Refer to the CoreCreator User Reference for a 
description of this flow function. From the command line, core packaging is 
achieved using the corepackage utility. The corepackage utility is described 
in the CoreCreator User Reference . 



SOCIntegrator and SOCBuilder 

This section describes the steps required to go from a set of packaged cores 
to a completely integrated SOC as represented by a mapped netlist. Refer to 
Figure 19 on page 28. 

Import Core 

Packaged cores must be unpackaged to bring them into the SOCIntegrator 
environment. In the SOCCreator GUI. there is an Import Core function to 
achieve this. From the command line, simply use the Unix tar command to 
extract the cores that were packaged in CoreCreator, 

Connect & Configure 

The SOC is assembled out of a set of cores and a SiliconBackplane. The cores 
are instantiated and plugged into the SiliconBackplane. Next, the 
SiliconBackplane and its agents are configured. At this stage the basic 
SiliconBackplane parameters (address map. bandwidth allocation, flag 
configuration) and many other agent options are configured. The goal of this 
step is to create a fully-connected SOC that satisfies the overall system 
requirements. Requirements such as performance, protocol adherence, chip 
area, and timing are tested via simulation and synthesis, and adjustments are 
made to the configuration as needed. 

In the GUI, the SiliconBackplane and the cores are instantiated by selecting 
them from the core catalog. The cores are connected to the SiliconBackplane 
in the design window. The design window is also used for configuring the 
SiliconBackplane and its agents, by double-clicking on the entity to be 
configured. The operations available from the SOCCreator design window are 
described in this document. 

From the command line interface, connection and configuration are achieved 
by describing the SOC in the RTL configuration file. The format of this file is 
described in the SonicsIA Hardware Reference, 
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Create Netlist 

Once the connection and configuration of the SOC has been described, a 
netlist can be created. In this step, the agents making up the 
SillconBackplane are created, each according to the requirements imposed by 
their configuration, the attached core, and the system. In addition, the 
SillconBackplane agents and cores are all wired together to form the chip. 

In order to prepare the system for simulation, a system-level test bench is also 
needed, which at a minimum provides a clock and reset signal to the chip. A 
sample minimum system test bench is included In the SonicsIA Hardware 
Reference, More typically, there are additional files to describe other pieces of 
the chip (such as the I/O pad ring) and other pieces of the system-level test 
bench (such as DRAM models). 

In the GUI. there is a dedicated flow button for netlist creation. From the 
command line interface, the soccomp tool accomplishes this step. The 
soccomp command is described in Chapter 6. 

Simulation 

Now the system is ready to be simulated. As in CoreCreator, simulation Is 
divided into three steps: prepare simulation, simulate, and analyze results. 
Once again, there is a test bench section In the chip RTL configuration file 
that associates a method with each chip core instantiation for each step of 
simulation. There is also a test file that specifies which methods to run and 
what arguments (specifying the test programs or analysis options, for 
example) to use for a given simulation run. See the SonicsIA Hardware 
Reference for more details about the test bench, as well as a sample test file. 

In the GUI. the test bench section is set up using the Define Test Bench flow 
button. The test file is created using a text editor and selected using the select 
test file flow button. Once these set-up steps have been accomplished, the 
three steps of simulation are each kicked ofi" with their individual flow 
buttons. Refer to Chapter 4 for a description of these flow functions. 

From the command line interface, the test bench section is Inserted into the 
chip RTL configuration file using a text editor. Similarly, the test file is created 
using a text editor. The SonicsIA Hardware Reference describes the format of 
these files. Hie three steps of simulation are accomplished with the 
simprepare, simrun, and simanalyze commands. Alternatively, all three can be 
launched in sequence with the simall command. Refer to the tool descriptions 
in Chapter 6 for more information about these commands. 
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Synthesize 

Logic synthesis is the primaiy function of SOCBuilder, During synthesis, the 
core and agent F?TL files as well as the SOC netlist created earlier are mapped 
to a specific cell library using a commercial synthesis tool. The output of this 
step is a mapped netlist that is combined with additional pieces, clocking, test 
and pad structures to complete the SOC chip design. 

In order to run synthesis, a number of items must first be set up. Global 
parameters such as clock constraints and technology-dependent parameters 
are specified in the chip synthesis configuration file. Technology-dependent 
parameters can be extracted from the target cell library using the Technology 
Compiler tool, techcomp, from the command line. For each core, there are 
core synthesis constraint files to describe the core's timing constraints and a 
synthesis script to guide the core through synthesis. Ideally, these files are 
delivered with each packaged core, but if missing they can be entered at this 
point. Also, any constraints supplied with the core synthesis configuration 
files can be overridden from the chip synthesis configuration file. Refer to the 
SonicsIA Hardware Reference for an example of a chip synthesis configuration 
file, as well as for the syntax of that file. See Chapter 6 for more information 
about the parameters of the Technology Compiler, techcomp. 

In the GUI, the chip synthesis configuration file is created and updated by 
supplying the required technology and clocking constraints. The technology 
Information is added into the file using the Edit > Technology menu item, and 
clocking information is added using the Edit > Clocks menu item. Port 
constraints, the default values of which come from the corresponding core 
synthesis configuration files, can be modified through the configuration 
panes of the cores and agents. Once setup is complete, sjoithesis is launched 
using the Synthesize flow button; see Chapter 4. 

From the command line Interface, technology information, clocking 
constraints, as well as port constraint overrides are specified by using a text 
editor to create a chip synthesis configuration file. The format of this file is 
specified in the SonicsIA Hardware Reference, Synthesis is then run using 
socmap. Refer to Chapter 6 for more information about the socmap utility. 



1 



Configuring Your Design 



The following sections give a brief overview of each GUI configuration dialog. 
Complete, parameter-specific configuration information can be found In the 
SonicsIA Configuration Guide and the SonicsIA Hardware Reference. 

As described on page 12, there are several ways to access the configuration 
dialog of any configurable object, whether it is a SiliconBackplane. agent, 
core, connection, or monitor: 

• Select the object to configure and choose Edit > Configure. 

• Double-click on the configurable object. 

• Place the mouse pointer over the configurable object, right-click, and 
choose Configure firom the Shortcut Menu. 



You may also configure your system by manually editing RTL configuration 
files (*rtl.conf) and synthesis constraint files (♦syn.conf). To do so correctly, 
however, requires a detailed understanding of SonicsIA and the sjnntax of 
these configuration files. 
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Dialog Basics 

Options in dialogs and panes appear grayed out when they are not applicable. 
They are dynamically enabled or disabled depending upon your configuration. 

The number and type of configuration options available depend on the object 
being configured. Some instances have a large number of configurable 
options while others have a small number in comparison. 

The term "dialog" refers to any queiy window that appears, asking you to 
enter or verify information. Sometimes It contains more information than fits 
in one window so the dialog is divided into tabbed panes. A "pane" describes 
the information under one tab. 

Buttons labeled OK and Cancel appear at the bottom of dialog and pane 
windows. Press OK to save any changes made to a window and exit. Press 
Cancel to exit without saving changes. 

Note that switching from one pane to another on a multi-tabbed dialog saves 
any changes made to a pane and cannot be undone with the Undo command. 
To avoid saving changes to a pane, be sure to press Cancel before moving to 
another pane. 

A default name appears whenever you create an object, but this name can 
be altered in the name field on the configuration dialog. Almost all names are 
visible from the design window. fThe OCP monitor and external interface are 
the only objects whose names can only be seen through the configuration 
dialog and not through the design window.) 
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Balloon Help 



To leam which parameter corresponds to a particular GUI field, move the 
mouse pointer over the option in the configuration pane and hold the pointer 
still for a moment. The parameter name appears in the balloon help. 
Parameter names are used in text files such as the rtl.conf file. They are also 
useful for identifying and referencing parameters in the SonicsIA Hardware 
Reference or SonicsIA Configuration Guide, 

The balloon help message on a locked, or non-configurable parameter 
includes the text (Locked by Core) under the parameter name, see Figure 24 
for an example. 

Special balloon help appears for Clocking panes and for Input Ports and 
Output Ports panes. When the cursor rests over a value, the valid range for 
that parameter and attribute appears in a balloon help bubble. Figure 25 
contains an example. 

In the following figure, the pointer rests over the OCP burst mode option and 
the parameter name. BURST, appears in the balloon help. 

Figure 23 Sample Balloon Help, Standard 
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Balloon Help 

showing parameter name 



The next figure shows an OCP dialog with locked parameters. The cursor rests 
over a non-conflgurable parameter so the balloon help message includes 
(Locked by Core) under the parameter name, BURST. If you are reading this 
document in color, notice that the dialog text also appears in a diflferent color 
(the default is dark blue) to indicate the value is locked. 

Figure 24 Sample Balloon Help Showing a Locked Value 



>^Configure Open Core Piotocol 



Cowwection-ltBinc: [bcpl 6 
J BuretMocte 




Balloon Help 

showing a locked parameter name 



46 SOCIntegrofor and SOCBuilder User Reference 



In the figure below, the cursor rests over a parameter attribute and the 
balloon help shows the valid range for the value. 

Figure 25 Sample Balloon Help Showing Valid Range 



><'Con(igufe Taigel Agent Module 



SBpplimB W ^Driving CM 



tpSF%.i 

tpSlltfeadlDJ : ; > 
tpStati«J_ ; . , ^■■^■j 

SisbCmdjmuj ;: : 

SMsbDatia^ftnWj 
sbnagHum.fimidJ 
BbRRstn ftnffl i V > 















jo 871? 




(|a8/lnytri2)<ift< 




;|5/l| range (5434:20^ i jlaSflnyfriZx^ 


-|q;482 i^;: 








'■■'i^o 




IP 8844: 


aulq.o^ 


. (la^nytri><^ 


,|afl844: 




- |la8/lnytr_^flX ^ 


|Q.88|*f», ' 




jlas/lnytr.Zx/X 


|0.8844>: 


■v?'|p.O:: -;v. 


|la8/lnvtr_" 


10.884^ : ■ 




. [las/lnvti ' 


Ja8844 


V;|q.o 




|0.8844 








Inn 





Walloon Help 
showing the valid 
range for a value 



Ch 5; Configuring Your Design, Ust of Configuration Dialogs 47 



List of Configuration Dialogs 

The following lists display the name and page number for each dialog 
description, both in order of appearance and in alphabetical order. 



in Order of Appearance 



Configure Chip 48 

Configure External Interface 50 

Configure Open Core Protocol 51 

Configure Open Core Protocol Monitor 53 

Introduction to QC and QS Models 54 

Configure QCMaster 59 

Configure QCSlave 60 
Configure QCSplitMaster and QCSplitSlave 63 

Configure SlliconBackplane 64 

Configure SlliconBackplane Monitor 72 

Configure TargetAgent Module 73 

Configure InlUatorAgent Module 80 

Configure ServiceAgent Module 85 



In Alphabetical Order 



Configure Chip 48 

Configure External Interface 50 

Configure InltiatorAgent Module 80 

Configure Open Core Protocol 51 

Configure Open Core Protocol Monitor 53 

Configure QCMaster 59 

Configure QCSlave 60 
Configure QCSplitMaster and QCSplitSlave 63 

Configure ServiceAgent Module 85 

Configure SlliconBackplane 64 

Configure SlliconBackplane Monitor 72 

Configure TargetAgent Module 73 

Introduction to QC and QS Models 54 
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Configure Chip 

The Configure Chip dialog allows you to name your design and to specify 
design-level settings for input and output ports. 



Main Pane 



As described in Chapter 1 , "The Basics", you can rename your chip from the 
Main Pane of the Configure Chip dialog. There are several different files and 
filenames associated with a chip. The chip name is the name in the chip 
command of the rtl.conf file and is used as the name of the top Verllog or 
VHDL module. This chip name also senses as the default base for the chip 
filename (rtl.conf file), and for the synthesis constraints file (syn.conf file). 

Figure 26 Sample Configure Chip, Main Pane 
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Input Ports and Output Ports Panes 

These values are the port synthesis constraint settings. The size of these 
panes varies and depends on the complexity of the design. 

Input ports panes and output ports panes remain disabled until technology 
parameters and clock information are defined. 

Ports appear on the pane sorted by interface then by port name. 

Navigating the Table 

The ports pane resembles a spreadsheet: you can navigate the table using the 
up and down arrows. Shift key + left: and right arrows, and the Tab key. The 
pane, however, does not automatically scroll to foUow the cursor so you must 
use the scroll bar along the right side of the window to page up and down 
the list. 

You can also use keyboard shortcuts to copy and paste values, Ctrl+C and 
Ctrl+V. respectively. The left and right arrows (without the Shift key) allow you 
to move through text character by character. 
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Values and Expressions 

Values associated with a port appear in table format to the right of the name. 
To change a vsdue: click on the value and enter a new one. 

To edit a Tcl expression: click on the value » view the expression In the Edit 
Expression line at the top of the pane, key In any changes to the expression 
In that line, and press Return. A recalculated value appears. 

Figure 27 Sample Configure Chip, input Ports Pane 
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Figure 28 Sampie Configure Chip, Output Ports Pane 
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Configure External Interface 



An external interface provides a connection to the chip I/O pads or to parts 
of the design that are not described In the chip file. 

From the configuration dialog for an external interface, you can alter the 
Interface name and interface type, as well as view the bundle type. To change 
the name of the Interface, enter the name In the "Interface Name" field. 
To change the Interface type, click on the upside-down triangle to see the 
available options for the currently selected external Interface and select the 
appropriate Interface type. The Interface types available depend on the core 
(or agent) to which the currently selected external interface is connected. The 
bundle type is also determined by the core (or agent), but It is not configurable 
so It appears grayed out. 

Figure 29 Sample Configure External Interface Diaiog. Example 1 
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Figure 30 Sampie Configure External interface Dialog, Example 2 
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Configure Open Core Protocol 

The OOP defines a family of polnt-to-polnt. bus- independent interfaces using 
a master-slave transfer model. This dialog allows you to view or define the 
specific characteristics of an OOP interface or connection. The designer of an 
individual core may specify a member of the OCP family that matches the 
capabilities of the core. The family members differ based upon data transfer 
model, sideband control signaling, and support for concurrency. 

Specific OCP connections inherit restrictions from the cores to which they 
connect. These restrictions frequently prevent you from modifying an OCP 
parameter that has been pre-determined by an attached core. The full range 
of family members is available only when both sides of the connection are not 
restricted. This is typically only true when a flexible behavioral model (such 
as QCMaster or QCSlave) is attached to a flexible SiliconBackplane agent 
(such as InitiatorAgent or TargetAgent. respectively). 

If any configuration parameters have been inherited from a core, then those 
parameters appear locked on this dialog. The balloon help message on a 
locked, or non-configurable parameter includes the text (Locked by Core) 
under the parameter name, see Figure 24 for an example. The dialog text also 
appears in a different color than configurable settings (the default "locked" 
color is dark blue). 

You can access OCP settings by configuring the connection on the OCP dialog. 
An example dialog appears in Figure 31 . You can also access OCP settings by 
configuring the core. This is useful when you have several OCPs on a core and 
want to modify all the OCP settings at the same time. A core's configuration 
dialog contains an OCP pane^ for each OCP module interface. An example 
pane follows in Figure 32 on page 52. 

Note that in order to change the connection name for an OCP, you need to 
change this name on the OCP connection dialog (not on the core dialog or OCP 
monitor dialog). 



Figure 3 1 Sample Configure Open Core Protocoi Diaiog 
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1 . The tenn "dialog" refers to any query window that appears, asking you to enter or 
verify information. Sometimes it contains more information than fits in one 
window so the dialog is divided into tabbed panes. A ''pane*' describes the 
information under one tab. 
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Figure 32 Sample Configure Open Core Protocol Pane 
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For more information about OCP, please refer to the Open Core Protocol 
Hardware Reference, For specifics on parameter configuration, consult the 
SonicsIA Coripguration Guide, 
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Configure Open Core Protocol Monitor 

An OCP monitor Is a behavioral module that logs activity on an OCP 
connection. These logs can be post-processed using the OCP tools. 

In addition to logging activity on the OCP, an OCP monitor can be configured 
to end the simulation when the attached OCP has been idle for a specified 
number of cycles. To force such an exit, generally speaking, onfy one OCP 
monitor in the design needs to be configured to do so. 

The OCP monitor can also generate a Waveform Generation Language (WGL) 
file for later use In a manufacturing test environment. 

Figure 33 Sample Configure Open Core Protocol Monitor Dialog 
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Introduction to QC and QS Models 

The QC and QS models are behavioral models that you can use In your design 
to model cores or to model the rest of the system. 

QC stands for Quick Core; QC models are used in SOCCreator. A Quick Core 
Master, QCMaster, models a master core. Similarly, a Quick Core Slave. 
QCSlave, models a slave core. 

QS stands for Quick System; QS models are used in CoreCreator (but are also 
available in SOCCreatoi), A Quick System Master. QSMaster. models the rest 
of the system to a slave core. And similarly, a Quick System Slave. QSSlave, 
models the rest of the system to a master core. 



Figure 34 QCMaster and QCSlave in SOCCreator 
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Figure 35 QSI\/lasfer and QSSlave in CoreCreator 
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OCP Pane 

OCP panes only appear in instances with configurable OCP Interfaces. The 
label that appears at the top of an OCP pane is the instance name of the port 
that the pane configures. 

For more Information, refer to "Configure Open Core Protocol" on page 51. 

Input Ports and Output Ports Panes 

These values are the port synthesis constraint settings. The size of these 
panes varies and depends on the complexity of the design. 

Input ports panes and output ports panes remain disabled until technology 
parameters and clock information are defined. 

Ports appear on the pane sorted by Interface then by port name; ip come first, 
then tp. followed by the rest of the interfaces In alphabetical order. 

Navigating the Table 

The ports pane resembles a spreadsheet: you can navigate the table using the 
up and down arrows. Shift: key + left and right arrows, and the Tab key. The 
pane, however, does not automatically scroll to follow the cursor so you must 
use the scroll bar along the right side of the window to page up and down 
the list. 

You can also use keyboard shortcuts to copy and paste values. Ctrl+C and 
Ctrl+V, respectively. The left and right arrows (without the Shift key) allow you 
to move through text character by character. 

Values and Expressions 

Values associated with a port appear in table format to the right of the name. 
To change a value: click on the value and enter a new one. 

To edit a Tel expression: click on the vsilue. view the expression in the Edit 
Expression line at the top of the pane, key in any changes to the expression 
in that line, and press Return. A recalculated value appears. 

For specifics on parameter configuration, please consult the SonicsIA 
Conjiguration Guide, 
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Input Ports Pane 

Figure 6 1 Sample Configure TargefAgenf Module, Input Ports Pane 
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Figure 62 Sample Configure TargetAgent Module, Output Ports Pane 
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Configure InitiatorAgent Module 

The InitiatorAgent Module (IM) is a SillconBackplane agent that receives OCP 
requests from an attached master IP core and converts them Into legal 
SillconBackplane requests. The configuration of an IM's OCP Interface Is 
Inherited from the characteristics of the attached core. Like the rest of the 
SillconBackplane communication system, the configured IM is produced by 
the Create Netlist or soccomp command. 

Note that many of the IM panes include sections repeated from the 
TargetAgent Module, since the IM can include an embedded TargetAgent 
Module to support cores that are both system initiators and system targets 
(such as DMA engines). 

If the IM has an embedded TM, then the TM configuration can be made 
through this dialog. Otherwise, the embedded TM sections are grayed out 
because they are not applicable. 

Structural Pane 

The Structural Pane provides access to FIFO buffer depth, buffer sharing, and 
other structural parameters of the InitiatorAgent Module. This pane also 
provides access to TM structural parameters, whenever an IM includes an 
embedded TM. 

For specifics on parameter configuration, please consult the SonicsIA 
Configuration Guide, 

Figure 63 Sample Configure InitiatorAgent Module, Structural Pane 
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Clocking Pane 

The Clocking Pane Is very similar to that of the TargetAgent Module. The only 
extension is to provide separate control over fast IM to slow core timing 
parameters between the IM*s slave and the core's master OCP interfaces. 



Figure 64 Sample Configure InhiotorAgent Module, Clocking Pane 
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Design suite accelerates SOC development 

-9/16/1999 
EDN 

You use Sonics' FastForward integration system to develop your system-on-chip (SOC) designs. The system contains 
intellectual property (IP) that aids multiple-core integration and communication, the Sonics Integration Architecture (SonicsIA). 
and the Sonics Integration Suite of design tools. 

SonicslA's configurable, modular architecture has a standardized core interface and communication protocol between various 
cores, such as CPUs, memory blocks, and peripheral blocks. The architecture provides latency and bandwidth service to the 
cores, along with managing address mapping, control flow, interrupts, and other communication needs. 

SonicsIA includes SiliconBackplane, Open Core Protocol, and MultiChip Backplane. SiliconBackplane contains the protocols 
and interconnect stnjcture to manage interblock communications. SiliconBackplane is a processor-indeper»dent, distributed, 
multiple-master/slave, memory-mapped I/O protocol. It provides both the physical bus and the bus-arbitration functions, 
merging features such as address-based selection, read and write transfers, and pipelining. 

Open Core Protocol is an open standard defining a generic-core "bus wrapper," letting you develop cores independently of an 
on-chip bus configuration. The Protocol is a synchronous read/write protocol with variable widths and flow control connecting 
cores to the SiliconBackplane. Open Core Protocol makes the bus conform to a core's needs rather than having you devetop 
cores to meet bus specifications. MultiChip Backplane extends the on-chip SiliconBackplane for chip-to-chip communications. 
This backplane also lets you verify cores at speeds as high as 400 Mbytes/sec. 

The Sonics Integration Suite configures SonicsIA for a design's application and generates a top-level synthesized chip netlist 
for placement and routing. According to Sonics. an SOC employing SonicsIA and designed with the Integration Suite usually 
needs only one place-and-route operation. The Suite contains the SOCIntegrator for structural design and functional 
simulation, and SOCBuilder for driving logic-synthesis, timing-analysis, and test-coverage design tools. The Integration Suite 
also includes CoreCreator for developing, validating, and preparing cores for reuse. CoreCreator helps develop core 
representations, including instruction-set simulator and behavioral models, RTL description, testbench. synthesis scripts, and 
test vectors, that you need during various parts of your design. 

FastForward, with SonicsIA and Sonics Integration Suite, i : 

runs on Unix platforms. The Sonics Integration Suite has a 
$64,500 annual license fee. FastForward license fees vary, 
depending on Included core and tool license fees. 

Sonics. 1-650-938-2500, '.vww.sonicsinc.com . 
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Sonlcs spins SoC plug-and-play tool 

By Michael Santarini, EE Times 
September 07, 1999 (1:25 PM EDT) 

URL: http://www.eetimes,com/article/showArticle.ihtml?articleId = 18302778 

MOUNTAIN VIEW, Calif. — Startup Sonics Inc. has announced a new breed of technology 
that it says enables the plug-and-play of silicon intellectual-property while giving designers 
greater visibility into a design's interconnect. 

The company's FastForward SoC Rapid Integration System promises to allow designers to 
integrate multiple cores and logic blocks quickly on one chip via a backplane, sidestepping 
the use of multiple chip buses. The system also automatically controls interconnect In the 
design, allowing for detailed verification of system-on-chip designs. 

Gary Smith, chief EDA analyst at research firm Dataquest Inc., called the tool "a 
breakthrough technology" that goes beyond plug-and-play. 

"It's in a completely new category," said Smith. "I'm tr/ing to figure out a name for the 
category now, but the best I've come up with so far is behavioral interconnect compiler. 

"The tool has the plug-and-play feature of a platform system, but it is much more. It 
automates the interconnect process. It slices and dices the verification process and makes it 
attackable." 

James Fleury, senior vice president of sales and marketing at Sonics, said FastForward is 
targeted at simplifying and speeding the overall integration process. One way it does that is 
by eliminating the restrictions of microprocessor buses on the overall SoC process, Fleury 
said. 

"SoC is largely CPU-centric," he said. "Typically, designers pick a CPU for their design and 
are stuck conforming the rest of their design to the CPU's particular bus standard or are 
stuck creating custom interfaces to connect subsystems. What that does is create a maze of 
wires in a design that is largely unmanageable." 

Fleur/ said FastForward reduces SoC complexity, increases predictability and cuts SoC 
development time by 50 percent. 

The system is chiefly composed of the SonicsIA (Integration Architecture) and Sonics 
Integration Tool Suite. SonicsIA has three main components: the SiliconBackplane, 
MultiChip Backplane and Open Core Protocol (OCP). Likewise, the Sonics Integration Tool 
Suite has three tools: CoreCreator, SOCIntegrator and SOC Builder. 

Fleury said SonicsIA's SiliconBackplane provides the protocols and interconnect structure 
required to manage interblock interactions. He called the component a fully distributed 
multimaster and -slave, memory-mapped I/O, and processor-independent communication 
protocol for on-chip, point-to-point interconnect. 

The SiliconBackplane merges computing's address-based selection, write and read transfers 
and pipelining with such communications capabilities as bandwidth decoupling, latency and 
sideband signaling. Fleury said the component makes the SoC integration process very 
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observable for validation, test and debugging. He said that all the blocks in the system 
communicate through the SiliconBackplane and that each block can be tested standalone or 
in full SoC context. 

SonicsIA's MultiChip Backplane extends the SiliconBackplane protocol and provides chip-to- 
chip communications, allowing system partitioning and hardware prototyping with FPGAs 
and software development. 

The third component of SonicsIA, OCP, is an open standard that defines a generic bus 
wrapper for cores. Sonics offered an early spec of OCP to the Virtual Socket Interface (VSI) 
alliance, which used the technology for the transaction protocol portion of its on-chip bus 
model. 

According to Fleury, OCP is a synchronous read and write protocol with variable widths and 
flow control that connects blocks to the SiliconBackplane. 

In the Sonics scheme, designers use CoreCreator to put an Open Core Protocol wrapper 
around blocks of custom logic or any core, hard or soft, so that it will talk to the 
SiliconBackplane. CoreCreator can also be used to produce a set of core representations, 
including instruction-set simulator and behavioral models, RTL, testbench, synthesis scripts 
and test vectors. 

More cores 

Designers would then use SOCIntegrator to add the "componentized" core and other 
"integration ready" cores to SiliconBackplane agents on the SiliconBackplane. 

Next, designers would use SOCIntegrator to program the SiliconBackplane. Underlying the 
tool suite is a technology, called the SiliconBackplane Compiler, that Fleur/ said generates 
the connections between blocks based on user-programmable parameters. Designers 
specify bandwidth, latency, FIFO depth, address/data- bus width, control signals and more. 

Designers could also perform functional simulation of blocks or whole designs at this stage. 
"Users simply specify which parts of the design they want simulated," said Fleury. 

Designers would then feed cell libraries to SOCBullder and use SOCBuilder to guide the 
SiliconBackplane and componentized cores through Synopsys Design Compiler synthesis. In 
conjunction with synthesis, SOCBuilder produces the SiliconBackplane in RTL Verilog. Fleur/ 
said an upcoming version of the tool will create a VHDL SiliconBackplane. 

SOCBuilder also provides inputs for Synopsys' PrimeTime static timing analysis tool at the 
block and full-chip levels as well as pre- and post-layout. Further, it drives scan insertion for 
the SiliconBackplane and hooks up core test harnesses. 

NEC Corp. is a beta customer of the system. Kojiro Watanabe, senior vice president and 
general manager of NEC USA, said the tool provided NEC with a direct path from system- 
level design to VLSI implementation. "Within six weeks, the entire system-chip^s 
performance had been modeled and the SiliconBackplane configuration defined," he said. 

In addition, Watanabe said, no changes were required to the system architecture during 
logical or physical design. 
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Doug Fairbairn, an industry veteran and management consultant who served a stint as VSI 
Alliance president and now is a member of Sonics' technical advisory board, said the 
company "is filling all the cracks between what everyone has been working on in this area. I 
think FastForward is a true leap ahead for SoC design and the closest thing to plug-and-play 
that we have seen in the industry." 

Grant Pierce, president and chief executive officer of Sonics, said the company will employ a 
new business model to match the uniqueness of its offering. The company will draw upfront 
revenue from licensing the tool suite but will also draw per-part royalties for every silicon 
implementation of its backplane technology. 

The fee for a single Sonics Integration Suite annual license is $46,500 running on Sun 
Solaris, with pricing and longer-term options available. 

CEO Pierce said the 24-person, venture-backed Sonics plans to add 15 employees by year's 
end and to make an initial public offering within two years. 



